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REMARKS/ARGUMENTS 

Claims 1-65 and 67-86 are now pending in this application. By this amendment, claims 
1,31, 33-34, 37-40, and 50 have been amended. Following entry of this amendment, claims 1- 
17, 31-42, and 50-65 will be pending in the present application. For the reasons set forth below, 
the applicants respectfully request reconsideration and immediate allowance of this application. 

Restriction Requirement 

The Final Office Action at p. 16 requests a restriction of claims 40-41. MPEP §803(1) 
notes that the criteria for a proper requirement for restriction between patentably distinct 
inventions includes the following: (A) the inventions must be independent or distinct as claimed; 
and (B) there would be a serious burden on the examiner if restriction is not required. MPEP 
§802.02 states that "the examiner, in order to establish reasons for insisting upon restriction, 
must explain why there would be a serious burden on the examiner if restriction is not required." 
The Examiner alleges that "[t]he claims appears (sic) to be functionally not related to other 
elements used in configuring methods as recited in the scope of Claims 1-17." Even assuming, 
arguendo, that the Examiner's allegation is true, the allegation is still not an appropriate 
explanation for a serious burden as specified in MPEP §802.02, and, as such, is insufficient to 
establish a serious burden as required by MPEP §803(1). 

Further, in the current Office Action, the Examiner rejects claims 40-41 under 35 U.S.C. 
§ 103(a) as being unpatentable over RadiSys, "Platform Management - Universal Developer's 
Guide" (hereinafter "RadiSys") in view of "Intel Server System SSH4 Board Set". Since the 
Examiner has obviously examined claims 40-41 in order to reject these claims, the applicants 
respectfully submit that there would not be a serious burden on the Examiner if restriction is not 
required. Therefore, criteria B of MPEP §803(1) and §802.02 are not met, and thus, the request 
for restriction is improper. 

Double-Patenting Rejection 

Claims 40-41 were rejected on the grounds of nonstatutory obviousness-type double 
patenting over claims 17 and 18 of U.S. Patent No. 7,237,086. Since the double-patenting 
rejection becomes moot if claims 40-41 are withdrawn, the applicants request that the double- 
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patenting rejection be addressed after the arguments presented above with respect to the 
restriction requirement are addressed. 

Claim Rejections Under 35 U.S.C. 101 

Claims 31-42 were rejected under 35 U.S.C. 101, as being directed to non-statutory 
subject matter. Claim 3 1 has been amended to properly recite a system. As such, the claims 
depending from claim 31 are also proper. Withdrawal of the claim rejections under 35 USC 101 
is respectfully requested. 

Claim Rejections Under 35 U.S.C. 102(b) and 35 USC 103(a) 

Claims 1-17, 31-39, 42, and 50-66 were rejected under 35 U.S.C. 102(b) as being 
anticipated by RadiSys, "Platform Management: CP80 Platform Management Overview" 
(hereinafter "RadiSysl") and RadiSys, "Platform Management: Universal Developer's Guide" 
(hereinafter "RadiSys2"). 

Claims 40-41 were rejected under 35 U.S.C. 103(a) as being unpatentable over RadiSysl 
and RadiSys2 in view of Intel, "Intel® Server System SSH4 Board Set," (hereinafter "Intel"). 

Claim 1 

Amended claim 1 recites, inter alia, "detecting a first component of the plurality of 
components communicatively connected to the management module by querying a plurality of 
slave addresses, wherein the first component at a first slave address of the plurality of slave 
addresses is detected upon responding to the query...." In its rejection of claim 1, the Final 
Office Action cites RadiSysl. In particular, RadiSysl at p. 8 discloses that "management 
applications can query sensors in the distributed management system, and report sensor status to 
upper-level applications." RadiSysl does not disclose that a plurality of slave addresses are 
queried in order to detect a connected component. Instead, Radisysl discloses that the sensors 
are queried in order to retrieve the status of the sensor. The fact that RadiSysl discloses that the 
management applications can directly query sensors shows that the management applications 
have already detected of the sensors. 

The Final Office Action at p. 8 notes that Radisysl discloses the operation of a low-level 
API. However, Radisysl at p. 8 discloses that the low-level API merely allows management 
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applications to communicate with the BMC. The API has absolutely no relation to the detection 
of components communicatively connected to the management module. 

Amended claim 1 further recites that the detecting operation as previously described 
occurs "prior to the management module being configured to monitor a plurality of components 
communicatively connected to the management module and analyze, based on the monitored 
plurality of components, whether an event has occurred in the computer system." Again, 
Radisysl discloses that the management applications are capable of querying sensors. That the 
management applications are capable of querying sensors to retrieve their status necessarily 
indicates that the management applications are already configured to access and monitor the 
sensors. As such, the operation of the management applications as described in Radisysl cannot 
occur prior to the management module being configured to monitor a plurality of components 
communicatively connected to the management module. 

The Final Office Action does not cite RadiSys2 in the rejection of claim 1, although 
RadiSys2 is cited in the overall rejection of claims 1-17, 31-39, 42, and 50-66. It is respectfully 
submitted that RadiSys2 does not cure the deficiencies of claim 1 described above. In particular, 
Radisys2 at p. 5 discloses a process whereby a list of devices are polled on a regular basis. Thus, 
Radisys2 clearly discloses that the location of the devices is already known, and that the 
detection process merely verifies whether its known devices are operational. Radisys2 does not 
disclose that a plurality of slave addresses are queried in order to detect a connected component, 
as essentially recited in claim 1 . 

Accordingly, Radisysl and Radisys2, alone or in combination, do not teach, suggest, or 
describe each and every element of independent claim 1 . The applicants therefore submit that 
this claim is in condition for immediate allowance. The applicant further submits that claims 2- 
17 are also patentable because they contain recitations not taught by Radisysl or Radisys2 and 
because these claims depend from allowable independent claim 1 . Accordingly, the applicants 
submit that claims 1-17 are in condition for immediate allowance. 

Claim 2 

Claim 2 recites "transmitting a discovery request on each of the plurality of possible slave 
addresses" and "responsive to the transmitting act, receiving an acknowledgement response from 
the first component indicating that the first component is communicatively accessible on a 
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specific active slave address." In its rejection of claim 2, the Final Office Action cites Radisys2 
and particular notes "the communication diagram between System Management Software and 
devices using communication of IPMB slave addresses." However, the communication diagram 
(i.e., Figure 1 of Radisys2) does not disclose the transmission of discovery requests to each of a 
plurality of possible slave addresses or receiving an acknowledgement response from the first 
component indicating that the first component is communicatively accessible on a specific active 
slave address. The communication diagram merely shows the general connection between the 
system management software, the IPMI interface, and the IPMI subsystem. The specific 
recitations of claim 2 (e.g., transmission of discovery requests and the receipt of an 
acknowledgment response) are not disclosed by the communication diagram. 

The Final Office Action also cites Table 12 shown in Radisys2 at p. 21. Table 12 merely 
describes a command for forwarding sensor events "from device to device in order to implement 
second logs or event annunciation. The fact that sensor events can be forwarded from device to 
device shows that the sensor events are only transmitted to active slave addresses (i.e., those 
slave addresses that indicate an accessible component), as opposed to each of a plurality of slave 
addresses in order to determine the active slave address. 

Accordingly, Radisysl and Radisys2, alone or in combination, do not teach, suggest, or 
describe each and every element of dependent claim 2. The applicants therefore submit that this 
claim is in condition for immediate allowance for these reasons and the additional reasons 
addressed above with respect to claim 1 . 

Claim 4 

Claim 4 recites "issuing a discovery request on a possible slave address" and "after a 
predetermined period in time has passed from which the discovery request was issued on the 
slave address, repeating the issuing act until each of the plurality of possible slave addresses have 
been pinged." In its rejection of claim 4, the Final Office Action cites the Watchdog Timer 
described in RadiSys2 at p. 13. Radisys2 describes two Watchdog Timer commands. The first 
command is "Reset Watchdog Timer" and "is used for starting or restarting the watchdog timer 
from the initial countdown value set with the Set Watchdog Timer command." The second 
command is "Set Watchdog Timer" and "is used for initializing and configuring the watchdog 
timer. The command is also used for stopping the timer." 
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Nothing in these descriptions of the commands "Reset Watchdog Timer" or "Set 
Watchdog Timer" discloses "after a predetermined period in time has passed from which the 
discovery request was issued on the slave address, repeating the issuing act until each of the 
plurality of possible slave addresses have been pinged." Radisys2 merely describes a simple 
timer function. The application of the Watchdog Timer for "repeating the issuing act until each 
of the plurality of possible slave addresses have been pinged" is not disclosed in Radisys2. 

Accordingly, Radisysl and Radisys2, alone or in combination, do not teach, suggest, or 
describe each and every element of dependent claim 4. The applicants therefore submit that this 
claim is in condition for immediate allowance for these reasons and the additional reasons 
addressed above with respect to claim 1 . 

Claim 9 

Claim 9 recites "defining a plurality of description files, each description file 
corresponding to a component which may be included within a configuration for the computer 
system, wherein the plurality of description files each specify a component classification for the 
component corresponding to each description file and the type of information that may be 
provided by the component." In its rejection of claim 9, the Final Office Action cites Radisys2 
as describing "[t]he standard software created by the Developer's guide using the configuration 
commands with respect to a device in the IPMO subsystem." However, this recitation of 
Radisys2 does not disclose the claimed "description files" nor does it disclose that "the plurality 
of description files each specify a component classification for the component corresponding to 
each description file and the type of information that may be provided by the component." 

In particular, while Radisys2 at p. 13 describes a "Get Device ID" command which 
returns a "Radisys-specific device identifier," Radisys2 does not disclose that the Radisys- 
specific device identifier is compared against description files to identify the device. Because 
Radisys2 does not disclose description files, it follows that Radisys2 also does not disclose 
"wherein each of the components detected and identified corresponds to one of the plurality of 
description files" as recited in claim 3 1 . 

Accordingly, Radisysl and Radisys2, alone or in combination, do not teach, suggest, or 
describe each and every element of dependent claim 9. The applicants therefore submit that this 
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claim is in condition for immediate allowance for these reasons and the additional reasons 
addressed above with respect to claim 1 . 

Claim 31 

Amended claim 3 1 recites, inter alia, "discover previously undiscovered components that 
are communicatively accessible to the management module by way of a communication medium 
of the computer system...." Support for this amendment can be found at least in the instant 
application at. p. 17, line 26 to p. 18, line 14 (e.g., "discovery session" and "discovery requests"). 
The cited portion of the instant application also describes two examples of discovering 
components that are previously undiscovered. In one example, each accessible slave address is 
sequentially pinged. In another example, all accessible slave addresses are flooded with 
discovery requests. 

As previously described, RadiSysl at p. 8 discloses that "management applications can 
query sensors in the distributed management system, and report sensor status to upper-level 
applications." RadiSysl does not disclose discovering previously undiscovered components that 
are communicatively accessible to the management module. Instead, Radisysl discloses that the 
sensors are queried in order to retrieve the status of the sensor. The fact that RadiSysl discloses 
that the management applications can directly query sensors shows that the management 
applications have already been discovered and cannot be "previously undiscovered," as recited in 
claim 3 1 . 

Amended claim 3 1 further recites "identify the discovered components by comparing the 
detected components with a plurality of description files each describing a component which 
may be communicatively connected to the management module, wherein each of the components 
detected and identified corresponds to one of the plurality of description files." With regards to 
claim 9, which also recites description files, the Final Office Action cites Radisys2 as describing 
"[t]he standard software created by the Developer's guide using the configuration commands 
with respect to a device in the IPMO subsystem." However, this recitation of Radisys2 does not 
disclose the claimed "description files" nor does it disclose that the detected components are 
identified by comparing the detected components with the description files. 

In particular, while Radisys2 at p. 13 describes a "Get Device ID" command which 
returns a "Radisys-specific device identifier," Radisys2 does not disclose that the Radisys- 
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specific device identifier is compared against description files to identify the device. Because 
Radisys2 does not disclose description files, it follows that Radisys2 also does not disclose 
"wherein each of the components detected and identified corresponds to one of the plurality of 
description files" as recited in claim 3 1 . 

Accordingly, Radisysl and Radisys2, alone or in combination, do not teach, suggest, or 
describe each and every element of independent claim 3 1 . The applicants therefore submit that 
this claim is in condition for immediate allowance. The applicant further submits that claims 32- 
42 are also patentable because they contain recitations not taught by Radisysl or Radisys2 and 
because these claims depend from allowable independent claim 3 1 . Accordingly, the applicants 
submit that claims 31-42 are in condition for immediate allowance. 

Amended Claim 50 

Amended claim 50 recites, inter alia, "discovering a previously undiscovered first 
component of the plurality of components communicatively connected to the management 
module by querying a plurality of slave addresses, wherein the first component at a first slave 
address of the plurality of slave addresses is discovered upon responding to the query," As 
previously described, RadiSysl at p. 8 discloses that "management applications can query 
sensors in the distributed management system, and report sensor status to upper-level 
applications." RadiSysl does not disclose that a plurality of slave addresses are queried in order 
to discover a connected component. Instead, Radisysl discloses that the sensors are queried in 
order to retrieve the status of the sensor. The fact that RadiSysl discloses that the management 
applications can directly query sensors shows that the management applications have already 
discovered of the sensors and cannot be "previously undiscovered," as recited in claim 50. 

Accordingly, Radisysl and Radisys2, alone or in combination, do not teach, suggest, or 
describe each and every element of independent claim 50. The applicants therefore submit that 
this claim is in condition for immediate allowance. The applicant further submits that claims 51- 
65 are also patentable because they contain recitations not taught by Radisysl or Radisys2 and 
because these claims depend from allowable independent claim 50. Accordingly, the applicants 
submit that claims 50-65 are in condition for immediate allowance. 
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Claim 51 

The deficiencies of the rejection of claim 51 are addressed, at least in part, in the 
discussion above with respect to claim 2. 



Claim 53 

The deficiencies of the rejection of claim 53 are addressed, at least in part, in the 
discussion above with respect to claim 4. 

Claim 58 

The deficiencies of the rejection of claim 58 are addressed, at least in part, in the 
discussion above with respect to claim 9. 



Conclusion 

In view of the foregoing amendment and remarks, the applicants respectfully submit that 
all of the pending claims in the present application are in condition for allowance. 
Reconsideration and reexamination of the application and allowance of the claims at an early 
date is solicited. If the Examiner has any questions or comments concerning this matter, the 
Examiner is invited to contact the applicants' undersigned attorney at the number below. 

Respectfully submitted, 

HOPE BALDAUFF HARTMAN, LLC 



/Steven Koon Hon Wong/ 



Date: September 22, 2008 "Steven" Koon Hon Wong 
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1720 Peachtree Street, N.W. 
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Atlanta, Georgia 30309 
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